Extensible Liquidity Ads #1153

t-bast · 2024-04-15T13:58:49Z

Add the ability to advertise rates at which nodes wish to sell their liquidity. Buyers can then connect to sellers and request liquidity, at one of the advertised rates.

This can be used when creating a dual-funded channel, where both participants contribute to the funding transaction, and one of them is paid for (some of) their contribution. This can also be used to splice additional liquidity into existing channels, when splicing is supported.

We introduce an extensible payment_type field to control how the funding fees are paid. The only payment_type currently defined pays funding fees from the buyer's channel balance during the interactive-tx session, but it is easy to introduce different payment_types (to pay the fees using HTLCs for example).

LSPs may for example want to offer funding where fees are not paid immediately when creating the transaction, but instead taken from every future HTLC relayed on that channel (see lightning/blips#36). We create the ability for bLIPs to introduce new payment types, without affecting the BOLTs.

We don't add any constraints to the commitment transactions. Sellers should keep the channel open for at least a month, but there is no way to guarantee that. The seller could immediately close the channel, or splice funds out. It is up to the buyer to then blacklist that seller.

This PR is a concurrent design for #1145.

Credits to @niftynei for the original design.

07-routing-gossip.md

t-bast · 2024-04-15T14:04:17Z

@TheBlueMatt I believe this kind of design leaves enough room for introducing different types of leases and fee mechanisms, and would make it easy to support all LSP use-cases. It also makes it easy for bLIPs to introduce lease types, that would keep using most of the liquidity ads mechanisms. Let me know what you think!

07-routing-gossip.md

Add types and codecs for the extensible liquidity ads format proposed in lightning/bolts#1153.

JssDWt

From the first look this looks like a good extensible model for channel leases. I didn't find any obvious gaps.

07-routing-gossip.md

02-peer-protocol.md

tnull

Did a first pass, found just a few nits and questions so far.

I also like the extensible model, but have yet to spend more time thinking about the details regarding how this would work in a JIT flow exactly.

02-peer-protocol.md

07-routing-gossip.md

Add types and codecs for the extensible liquidity ads format proposed in lightning/bolts#1153.

The last commit of lightning/bolts#1153 introduces a separate `payment_type` field, that allows extending the ways fees can be paid.

niftynei

While this is a considerable evolution of the original proposal, I think it's fair to ask that that I get at least a by-line credit the commit description for this. For example something like

Credit to: @niftynei for the original liquidity ads proposal

02-peer-protocol.md

07-routing-gossip.md

t-bast · 2024-05-21T09:01:36Z

While this is a considerable evolution of the original proposal, I think it's fair to ask that that I get at least a by-line credit the commit description for this. For example something like

Of course, I'd like to re-arrange the commits once reviewed (the first commit is only here to help guide the review and shouldn't be included on master IMO), once we get closer to a final version I'll clean-up the commits and add credits!

We previously only used liquidity ads with splicing: we now support it during the initial channel opening flow as well. This lets us add more unit tests, including tests for the case where the node receiving the `open_channel` message is responsible for paying the commitment fees. We also update liquidity ads to use the latest version of the spec from lightning/bolts#1153. This introduces more ways of paying the liquidity fees, to support on-the-fly funding without existing channel balance (not implemented in this commit). Note that we need some backwards-compatibility with the previous liquidity ads types in our state serialization code: when we're in the middle of signing a splice transaction, we may have a legacy liquidity lease in our splice status. We ignore it when finalizing the splice: the only consequence is that we won't store an entry in our DB for that lease, but the channel will otherwise work correctly.

The initiator of `open_channel2`, `tx_init_rbf` and `splice_init` can request funding from the remote node. The non-initiator node will: - let the open-channel-interceptor plugin decide whether to provide liquidity for new channels or not, and how much - always honor liquidity requests on existing channels (RBF and splice) when funding rates have been configured Liquidity ads are included in the `node_announcement` message, which lets buyers compare sellers and connect to sellers that provide rates they are comfortable with. They are also included in the `init` message which allows providing different rates to specific peers. This implements lightning/bolts#1153. We currently use the temporary tlv tag 1339 while we're waiting for feedback on the spec proposal.

We previously only used liquidity ads with splicing: we now support it during the initial channel opening flow as well. This lets us add more unit tests, including tests for the case where the node receiving the `open_channel` message is responsible for paying the commitment fees. We also update liquidity ads to use the latest version of the spec from lightning/bolts#1153. This introduces more ways of paying the liquidity fees, to support on-the-fly funding without existing channel balance (not implemented in this commit). Note that we need some backwards-compatibility with the previous liquidity ads types in our state serialization code: when we're in the middle of signing a splice transaction, we may have a legacy liquidity lease in our splice status. We ignore it when finalizing the splice: the only consequence is that we won't store an entry in our DB for that lease, but the channel will otherwise work correctly.

The initiator of `open_channel2`, `tx_init_rbf` and `splice_init` can request funding from the remote node. The non-initiator node will: - let the open-channel-interceptor plugin decide whether to provide liquidity for new channels or not, and how much - always honor liquidity requests on existing channels (RBF and splice) when funding rates have been configured Liquidity ads are included in the `node_announcement` message, which lets buyers compare sellers and connect to sellers that provide rates they are comfortable with. They are also included in the `init` message which allows providing different rates to specific peers. This implements lightning/bolts#1153. We currently use the temporary tlv tag 1339 while we're waiting for feedback on the spec proposal.

We previously only used liquidity ads with splicing: we now support it during the initial channel opening flow as well. This lets us add more unit tests, including tests for the case where the node receiving the `open_channel` message is responsible for paying the commitment fees. We also update liquidity ads to use the latest version of the spec from lightning/bolts#1153. This introduces more ways of paying the liquidity fees, to support on-the-fly funding without existing channel balance (not implemented in this commit). Note that we need some backwards-compatibility with the previous liquidity ads types in our state serialization code: when we're in the middle of signing a splice transaction, we may have a legacy liquidity lease in our splice status. We ignore it when finalizing the splice: the only consequence is that we won't store an entry in our DB for that lease, but the channel will otherwise work correctly.

07-routing-gossip.md

The initiator of `open_channel2`, `tx_init_rbf` and `splice_init` can request funding from the remote node. The non-initiator node will: - let the open-channel-interceptor plugin decide whether to provide liquidity for new channels or not, and how much - always honor liquidity requests on existing channels (RBF and splice) when funding rates have been configured Liquidity ads are included in the `node_announcement` message, which lets buyers compare sellers and connect to sellers that provide rates they are comfortable with. They are also included in the `init` message which allows providing different rates to specific peers. This implements lightning/bolts#1153. We currently use the temporary tlv tag 1339 while we're waiting for feedback on the spec proposal.

SeverinAlexB · 2024-07-18T14:33:37Z

In todays LSPSpec call @tnull mentioned that you were talking about "paying LSPs to keep channels open" and he/I thought you were interested in our thoughts building the Blocktank LSP/Bitkit wallet at Synonym.

At Synonym, we talked about "clients paying the LSP to keep the channel open", or as we call it "channel subscriptions/extensions" a lot already internally. We haven't settled on a specific model yet but we imagine the following:

Client has a channel from the LSP from whatever method it acquired it from.
After the initially agreed channel lease period, instead of just closing the channel, the lsp sends the client an offer for a lease extension to keep the channel open for an additional amount of time.

// Something like
extensionOffer: {
  currentLeaseEndsAt: "2024-07-23T18:25:43.511Z",
  extensionDurationDays: 365,
  invoice: "...ln invoice...",
  scid: "..."
}

If the client pays the invoice all is good and the lease gets extended.
If the invoice never gets paid the LSP closes the channel.

There are multiple ways to implement this UX-wise, like monthly subscriptions, yearly payments and with discounts based on routing fees earned. It's going to be tricky to create a unified UX over all LSPs.

I suggest this to be an independent blip/LSPS and not to tie it to a funding method like LiqAds.

t-bast · 2024-07-18T15:04:39Z

Thanks for the comment @SeverinAlexB.

I suggest this to be an independent blip/LSPS and not to tie it to a funding method like LiqAds.

I agree, this is independent of liquidity ads since it doesn't involve doing an on-chain transaction, while liquidity ads is a tool for negotiating the parameter of a collaborative on-chain transaction. For the use-case you describe, a Bolt 12 offer with recurrence seems to be what makes the most sense.

For actually creating that channel in the first place, I believe you could use liquidity ads though, and a tool like on-the-fly funding!

SeverinAlexB · 2024-07-19T06:26:52Z

a Bolt 12 offer with recurrence seems to be what makes the most sense.

Yes, that could be a great fit.

For actually creating that channel in the first place, I believe you could use liquidity ads though, and a tool like on-the-fly funding!

Fully agree.

The initiator of `open_channel2`, `tx_init_rbf` and `splice_init` can request funding from the remote node. The non-initiator node will: - let the open-channel-interceptor plugin decide whether to provide liquidity for new channels or not, and how much - always honor liquidity requests on existing channels (RBF and splice) when funding rates have been configured Liquidity ads are included in the `node_announcement` message, which lets buyers compare sellers and connect to sellers that provide rates they are comfortable with. They are also included in the `init` message which allows providing different rates to specific peers. This implements lightning/bolts#1153. We currently use the temporary tlv tag 1339 while we're waiting for feedback on the spec proposal.

We previously only used liquidity ads with splicing: we now support it during the initial channel opening flow as well. This lets us add more unit tests, including tests for the case where the node receiving the `open_channel` message is responsible for paying the commitment fees. We also update liquidity ads to use the latest version of the spec from lightning/bolts#1153. This introduces more ways of paying the liquidity fees, to support on-the-fly funding without existing channel balance (not implemented in this commit). Note that we need some backwards-compatibility with the previous liquidity ads types in our state serialization code: when we're in the middle of signing a splice transaction, we may have a legacy liquidity lease in our splice status. We ignore it when finalizing the splice: the only consequence is that we won't store an entry in our DB for that lease, but the channel will otherwise work correctly.

Creating a new channel has an additional cost compared to adding liquidity to an existing channel: the channel will be closed in the future, which will require paying on-chain fees. Node operators can include some `channel_creation_fee_sat` to their liquidity ads to cover some of that future cost.

t-bast · 2024-09-03T13:09:17Z

Note to reviewers: I slightly changed the format of funding rates in the last commit to include an additional fee for channel creation. As detailed in the commit message, creating a new channel doesn't have the same cost as adding liquidity to an existing channel (in terms of resources and future on-chain usage): this lets node operators collect a different fee for channel creation to hedge the cost of a future (force) close.